1. Field of the Invention
This invention relates to apparatus and processes for verifying an object-oriented program, and more particularly to apparatus and processes for merging types when verifying Java or other object-oriented programs.
2. Background of the Invention
The Java virtual machine (JVM) is a Java interpreter and platform-independent execution environment. Java source code or other source code may be compiled into a format known as Java bytecode. This bytecode may then be executed on a JVM installed on a particular machine. Web browsers and other web-based software are often equipped with JVMs. The Java platform is designed to be inherently “safe,” meaning that it is difficult for a program to crash the host machine or interfere inappropriately with other operations on the host machine. This allows certain functions and data structures belonging to “trusted” code to be protected from access or corruption by “untrusted” code executing within the JVM.
One way that the JVM provides safety is by providing “type safety.” Type safety requires programs with type errors to produce error indications rather than execute the programs and produce erroneous results. Type safety is helpful to develop and debug program code, but more importantly prevents erroneous executions that can be exploited to introduce security flaws. Because JVM bytecode may be transmitted over the Internet and executed remotely, the JVM needs to determine whether class files were produced by a trustworthy compiler or by an adversary attempting to exploit the virtual machine.
Accordingly, the Java specification requires that Java classes loaded by the JVM are verified prior to being executed. Verification is a compiler independent process that verifies that a class satisfies various structural and static constraints. For example, the JVM verifier may keep track of the types operated on by the bytecode. For example, if the bytecode is invoking string behavior (indicates that it is operating on a string), the JVM verifier may verify that the object being operated on is actually a string. If the program code is not operating on the type that is indicated in the code, the program may generate undefined behavior (e.g., crashes), unpredictable behavior, or allow untrusted programs to compromise security.
One task that the JVM verifier performs when verifying types is “type merging.” Type merging is performed where two or more different code paths, each operating on a different type, merge together into a single code path. The JVM verifier may merge the types operated on by the different code paths into the least common superclass for each type. In many cases, a valid merge may require loading each class along with its full hierarchy. In fact, where the classes are different and neither class is the java.lang.Object class, the merge may result in loading the complete hierarchy for both classes.
In some cases, the merge will provide no value because the types may merge to the most generic Java class (i.e., the java.lang.Object class). In other cases, a merge may unnecessarily consume resources because the merged type may not be needed later in the method (i.e., a subroutine of a class or object). In either case, the merge may result in excess and unnecessary class loading which may have a negative impact on application startup time and memory usage.
In view of the foregoing, what is needed is an apparatus and process to optimize performance and resource utilization when merging types. Ideally, such an apparatus and process would reduce or minimize the number of classes that are loaded when merging types.